IBIS Macromodel Task Group Meeting date: 22 March 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad noted that he and Bob Ross had each created some slides related to the referencing topic. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - None ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Reference [Model]s in IBIS: - Bob: [Sharing his new presentation] - Summary: Many Topics - C_comp connected to GND. - Reference Models used in EDA tools. - Some C_comp issues. - Some extraction assumptions and methods. - [Slides 3, 4] - Figure 11 - Terminator [Model] figure. - C_comp connected to GND (IBIS 5.0), now ground symbol (6.1). - Note that Rac and Cac are also connected to the same "ground". No specific solution for them. - [Slide 5] - Figure 15 is just an extraction setup for waveform measurement. - It defines the R_dut, L_dut, C_dut, which emulate a package if you have to extract by measurement. - Unfortunately, this method is flawed and most tools don't support R_dut, L_dut, C_dut at all. - Not recommended. - In my opinion, it is irrelevant, because there are better ways to de-embed the package information. - C_comp is embedded in the DUT die anyway. - [Slide 6] - [Composite Current] extraction figure. - It's defined from the [Pullup Reference]. - Radek: "C_comp not needed" is a bit misleading? - Bob: - C_comp is also embedded in the "DUT die" in this figure. It is not shown as a separate element (that is what is meant by the phrase "C_comp not needed" on the slide). - [Slide 7] - Figure 17 actually shows some internal currents. - This figure doesn't show C_comp, so there is inconsistency when we break up internal currents. - That's what we have in IBIS. - We have some details but are missing others for a general configuration. - [Slide 8, Slide 9] - I've shown some EDA Tool Reference [Model]s documented by some tools. - In all cases the user can override the C_comp to ground (effectively creating C_comp_xxx behavior). - My conclusion is IBIS should not change its reference model because the tools will not change theirs. - I don't know what all other tools do. - Randy: Although the HSPICE documentation appears to be behind, they have changed their behavior as of late 2015 to connect C_comp to pd_ref. - Walter: SiSoft in its internal SPICE simulator also hooks C_comp to the gc_ref or pd_ref. We use a local ground not earth ground. - We have various EDA vendors documenting that they do it both ways. - Radek: We may have the local ground being separate from the pd_ref or gc_ref, but not necessarily make it global ground. - You just allow everything to be referenced to a different single node. - It wouldn't change the picture, just the interpretation of the ground symbol. - Ming: We also give the user the option to split the basic C_comp. - Bob: Yes, all tools do as far as I know. - But you do not automatically connect C_comp to pd_ref or gc_ref, right? - Radek: No, there is nothing in the spec that would suggest that explicitly. - Bob: So we have different tools doing thing differently. - [Slide 10] - From the IBIS cookbook. Diagram from Arpad's work. - C_comp is Not constant. - Extraction generally assumes all rails are ideal, so what you get is the overall C_comp. - [Slide 11] - From the cookbook. Arpad proposed one method for deriving the individual C_comp_xxx values from simulations. - [Slides 12, 13] - Results from Lance Wang's IBIS Summit Tokyo presentation. - Plots show the total C_comp and his results when he extracted the individual split C_comp values. - In his example, C_comp_pc was actually the dominant term. - This counter example shows that arbitrarily deciding that C_comp goes to pd_ref or gc_ref is technically questionable. - [Slide 14] - IBIS [Model] Extraction - From Simulation: - Remove the package then do extractions. - From measurement: - Much more complicated, details outside the scope of IBIS and even the cookbook. - [Slide 15] - EDA Tool IBIS Model Simulation - Various different approaches may be employed. - No one approach is "correct," so we should avoid defining certain fixed approaches in IBIS. - We agree that C_comp to "ground" provides a model that is probably not suitable to power aware analysis. - [Slide 16] - A more general IBIS I/O Reference [Model] - The separate C_comp_xxx values are shown. - [Slide 17] - Recommendations - Non power aware just keep the legacy C_comp to ground. - State that such models are not recommended for power aware analysis. - Add a new reference model diagram showing the C_comp_xxx connections (like Slide 16), since that is supported anyway. - Note that IBIS Model extraction from simulation assumes that package circuitry is removed. - Extraction details in IBIS cookbook should focus on simulation. - Details regarding extraction from physical measurements are outside the scope of IBIS or even the cookbook. - Arpad: With regard to [Slide 17], when you say "state", or "add", or "note" do you mean in the IBIS spec or in the model or where? - For example, "not recommended for power aware", or "Add a new reference model...", should those be added to the spec? - Bob: Yes, in the spec. - Radek: We have a C_comp_xxx option for the model maker that is unambiguous. - We can add a new reference figure. - If the model maker only gives us C_comp, we have to deal with that and how it is referenced, regardless of whether it is a power aware simulation. - For new models we can describe what to do. The recommendation to provide C_comp_xxx is a good one. - We still have to address how to handle C_comp if that's all that is given. - Arpad: I want to restate what several people have mentioned at various times, that this issue of where to connect C_comp is only relevant when non- ideal sources are used to power the buffers for a power aware simulation. - As soon as you use ideal sources then the connection point of C_comp is irrelevant because the ideal sources are AC shorts between all the terminals. - For that reason I still maintain that we should consider a solution for this C_comp connection that is relative to other keywords. For example, if [Pin Mapping] doesn't exist and there are multiple power and ground Pins then we cannot use them for power integrity purposes because we don't know which buffers are associated with which power and ground pins. One method for deciding if C_comp is valid is to look at whether the [Component] has a [Pin Mapping] keyword. Another would be look at whether the [Model] has [Composite Current] or [ISSS_**] parameters. - I would suggest formulating a rule that if those keywords don't exist then it is okay to use C_comp, no matter what DC node is used for its reference, but if they do exist then the model maker should use C_comp_xxx, and if the model maker doesn't use C_comp_xxx then suggest that the tool split the value of C_comp evenly amongst various C_comp_xxx. - Radek: My understanding of Bob's example from Lance [Slide 12] is that there is no reliable way to decide how to split C_comp. - We are dealing with non-linear devices. - For example, if the gc_ref shifts from zero, then it shifts the point at which clamping occurs and this significantly affects the buffer's operation. - We can't arbitrarily move C_comp from one place to another. - Bob: Radek's point is well taken. - The best algorithm we might have here is a 25/25/25/25% split assuming 4 terminals. - C_comp has lots of issues, but my main conclusion is that attaching it to one specific terminal is technically questionable. - Arpad: It's only questionable if you're using non-ideal sources. - Walter: I agree with Arpad. - If you're doing a simulation with fixed rails then it doesn't matter. - You can hook C_comp to any DC rail and get the same simulation results. - When rails vary it can be for two reasons: - You have a power delivery model and the power rail could vary for external reasons. - The rail can vary due to current pulled by the buffer itself. - In that case it matters where C_comp is hooked up. - But as a practical matter, in simulation you'll generally find you get a bad result if you hook C_comp to node 0, but you generally do okay if you connect C_comp to any of the local references. - Arpad: I disagree with the last statement. - If I hook C_comp to the pd_ref and the power rail is what wiggles then you don't see anything in the signal. - Walter: Yes, it can make a difference. - But in reality, the large voltage variations tend to occur on both rails. - For practical purposes, if you model real power delivery systems then it usually works out. - Arpad: You could have a collapse when there's a crowbar momentary short circuit between the pu and pd terminals. - What about the interconnect models that are made such that the references all rely on node 0? Everything from the ground parasitics is figured in to the signal or the power lines. With that approach C_comp location would have serious consequences. If you hook it to pd_ref it would do nothing for you. You would have to hook it to pu_ref. - Walter: You mentioned the very important part. - The impact of clamping ground and using the universal ground reference for your power integrity is that your signal moves up and down. The signal moving up and down will have the exact same effect when you put C_comp to pd_ref as pu_ref, because the signal now moves up and down "half" as much as the power rail. - My point is that it's not so simple that it's obvious. - Model makers generally have no idea how to split C_comp up when they do an extraction. So most model makers just split it up evenly. - We have to deal with what we have. - We can force the model maker to split C_comp. - We might as well just have the EDA tool do it. - We both agree that for the purposes of power aware simulation C_comp must be split somehow between the local rail voltages. - Arpad: If we agree on this statement, then why don't we just add the new rule to the spec that "C_comp should only be used for non power aware IBIS models," which could be determined based on existence of certain keywords. - Walter: That only takes care of doing power aware simulations when we do have [Composite Current]. - Wouldn't you also want to support simulations where the rail voltages are moving because of external influences? - I agree with you. Without [Pin Mapping] we can't hook it up at all. - Arpad: If [Pin Mapping] exists you must have C_comp_xxx. - Walter: Yes, or say if it's not given the EDA tools splits C_comp up amongst the rails. - If that's not good enough, then the model maker should give C_comp_xxx. - Bob: Yes, we already have C_comp_xxx so the model maker can do it. - Suggested guidance may be for the tool to split C_comp equally. - But we should not mandate a connection to one particular rail. - Arpad: I don't think we should say how the tool should split it up. - Tool maker might give the user the option. - But we can say that if [Pin Mapping] exists you should not use plain C_comp. - Radek: I think we are going in the wrong direction in general. - We really need the definition of the local ground as well as the reference for the output signal. - This can be the same rail as the gc_ref or the pd_ref, and this is entirely up to the model maker. - We are trying to avoid this solution of specifying it fully. - We are trying to reinterpret old data in a different way. - It's entirely up to the user and not the EDA tool to know what kind of simulation is done and how to reinterpret the data. - Arpad: Are you saying we should provide another parameter in the model to say where C_comp should be connected if the model maker isn't using C_comp_xxx. - Radek: Yes, that's what I've been saying all along. - Arpad: Why not just tell the model maker to use the C_comp_xxx? - Why introduce another parameter to define the reference, when the model maker can just use the C_comp_xxx to produce the same effect. - Radek: That might work for C_comp for now, but what about the future? - What about defining a reference for the signal output itself? - We don't provide any means to say what the output signal is with respect to. - Arpad: Thank you all for joining. ------------- Next meeting: 29 March 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives